1. Field of the Invention
The present invention relates generally to telecommunication services monitoring and, more particularly to systems and methods for monitoring the availability of individual service package applications resident on a Service Node.
2. Background of the Invention
It is well-known to provide Advanced Intelligent Network (AIN)-based services that operate on a Service Node (SN). As shown in FIG. 1, a Service Node 25 is typically in communication with two Service Control Points (SCPs), SCP 15 and SCP 20, which are in communication with each other, all via an electronic network 3. Conventionally, this network is an X.25 network, but a TCP/IP network or Signaling System 7 (SS7) network has also been contemplated and implemented in certain cases. Employing a pair of SCPs provides redundancy and thus fault tolerance to network operations.
The remaining elements depicted in FIG. 1 are also well-known and include end user telephones 5a and 5b, a Service Switching Point (SSP) 10, typically a central office, and one or more Signal Transfer Points (STPs) 12a and 12b. SSP 10, STPs 12a, 12b, SCPs 15, 20 and Service Node 25 are all in potential communication with each other over electronic network 3, which, again, can be any one or combination of an X.25 network, a TCP/IP network and/or an SS7 network, as is well-known in the art.
The topology illustrated in FIG. 1 is employed by telecommunication service providers to deploy services that operate, primarily, from Service Node 25. Such services might include, for example, a voice mail system or a menu-driven information resource. In a typical service implementation, an SCP authenticates subscriber information and routes an incoming call to a particular service package application (SPA) running on a Service Node. The Service Node might be equipped, for example, with text-to-speech capabilities and/or Interactive Voice Response (IVR) capabilities. The Service Node or SPA collects information from the caller and delivers the information to the subscriber. The Service Node might also set up a connection between the caller and the subscriber, as needed. Since the Service Node plays a vital call connection role, the SCP preferably needs to know whether the Service Node and/or SPA operating thereon is in service before routing the caller to the Service Node.
In this regard, it is known to monitor the status of a Service Node with a Service Node status message, known as a “heartbeat,” which is generated at the Service Node and passed to the SCP, thereby providing periodic handshaking between these two components. In prior art implementations, however, each application (i.e., SPA) running on a Service Node that works in conjunction with an SCP typically includes its own heartbeat implementation, which results in multiple implementations of a heartbeat for multiple SPAs.
Thus, for example, if there are six programs running on a given platform or Service Node, there would likely be six separate iterations of heartbeat messaging mechanisms operating over electronic network 3 between a given SCP and Service Node. Not only is it a burden to have to develop a separate heartbeat mechanism for each SPA, but operating six separate heartbeat functions adds network overhead, thereby decreasing network and equipment efficiency.